Identify Issues by Hitting Tab
On this page
To setup the demo application start here → Intro & Setup
The first step in testing keyboard accessibility is to start hitting the Tab key to see what interactive items you can and can't reach.
This technique will work in any web browser, even on a mobile device with a Bluetooth keyboard.
It’s the fastest way to start determining if something was built with accessibility in mind.
On a Mac, you may need to adjust your OSX System Preferences to allow tabbing to all interactive controls: visit System Preferences > Keyboard > Shortcuts. In Safari,visit Safari > Preferences > Advanced.
🛠 Challenge: Search for Issues by Hitting Tab
Open up the CampSpots homepage and start hitting Tab.
As you hit Tab through links, watch your browser's status bar to see the URL of the item you have focused on.
Tab through the homepage until you have cycled all the way through and focus shifts to your browser’s address bar. Take note of any issues you find.
Repeat the process for the About page, which you can find in the “Resources” menu.
Use Live Expressions in DevTools to see where you are.
Chrome DevTools has a feature called Live Expressions that monitor JavaScript expressions and update as necessary. I like to add an event listener to the body for the focusin event and have it log out the active (focused) element as it goes through focusable children.
document.body.addEventListener('focusin', () => console.log(document.activeElement))
This will re-fire every time the active element changes and allow you to interact with it in the Elements panel to track down pesky half-hidden controls.
🛠 Solution: The Issues Found
When tabbing through the CampSpots app, here are some issues you should find:
- There isn’t much of a visual indication to where you are focused on the page.
- Several links have the only
#symbol, but this isn't a huge deal at the moment since this is a prototype app. - The Browser status bar sometimes shows that you have selected a link to a different page, but it doesn’t open a nav menu and you can’t see where you are visually in the mega menu ("Plan Your Trip", "Ways to Stay", "Resources").
- You could Tab into the form fields on both pages but hitting Tab again skips over the Submit button. Skipping the submit button with the Tab key could be acceptable if the form Submit was disabled until required fields were filled.
Video Transcript
let's start diving into the first thing that I would use to test a website for accessibility, which is the keyboard and with all of these exercises that we'll do today, my goal is to show you the most common steps that I use for accessibility testing.
Before we start building on with more complex topics, we we'll level set with techniques that you can use every day. I use these techniques every day to go and get a health check like what's going on with this website for accessibility or they say they're accessible. Let's go see how, how well they did.
So I, my hope is that these skills will be really portable so that you can test any website, any web application and get a good picture of the accessibility of it, starting with the keyboard. So in any web browser, including on mobile devices, if you had an auxiliary Bluetooth keyboard, for example, using the keyboard would be a fundamental way of navigating if you can't use a mouse or a track pad.
And so for my testing purposes, I can often test with the keyboard and very quickly figure out if something was made with accessibility in mind. So that means hitting the tab key. And right now I'm hitting tab and I don't see anything happening. I see down in the bottom left corner of my browser, I've got the status bar.
I'm gonna hide my dock. So I've got the status bar showing up here and I see some link URLs, but I don't have any visible focus style. I don't have any action from the mega menu. And if I keep tabbing well, I see my focus is in these input text fields kind of further down the page, but very little in the way of usable indicators to tell me where I am on the screen as a keyboard user, and to allow me to use the functionality.
So right away, I can tell there's some major things to fix on this website.
If we go over to our about page, we can go do a little keyboard check over here. So it's got the same mega menu, presumably one component that we can go and make changes to that would apply to both the homepage about page, any other page that's using this mega menu.
So if I tab through, I'm seeing all of these links in the status bar that are not visible on the screen. So that's definitely something we should go and fix. Similarly, I've got focus going into a text area further down the about page. But that's about it. There's no visible focus styles. So that's a problem.
Use Browser Developer Tools to Investigate Issues
Now that we’ve found some issues, let’s take a look at the markup to determine what’s going on.
A typical workflow is to identify a few problems, examine markup in DevTools, then jump over to the code to remediate the issues.
Even if you aren’t the one responsible for fixing issues, it’s worth practicing and experimenting with DevTools to gather more information. Changes you make in DevTools aren’t permanent and you can always refresh the page to start over!
Checking Focus Styles
The logo image links to the homepage, which was noticeable in the browser status bar. However, there was no indication that it had keyboard focus when we were tabbing through the page.
Right clicking the logo image and choosing “Inspect” will open the DevTools with the logo image highlighted in the Elements pane.
In the Styles pane of Chrome DevTools is an option to force interactive states (indicated with :hov). Click this option, then select the focus and focus-visible options.
When focus is forced, we should see an outline around the element.
Scrolling through the CSS shows us the problem— there is a wildcard selector (*) that has set the outline to none.
Unchecking this rule will display the focus outline around the logo link.
Removing this style from the stylesheet would fix this problem permanently. It’s unfortunately common to see this type of thing in the wild. But it’s also fortunately easy to fix, most of the time!
Checking the MegaNav
The MegaNav buttons (”Plan Your Trip”, “Ways to Stay”, “Resources”) aren’t focusable.
This is because they are marked up with divs instead of semantic button elements.
The div element is not focusable or operable by itself. If you see something that seems like a button but DevTools says it’s a div, that’s something that needs to be fixed.
Despite the menu controls not being focusable with the Tab key, all of the submenu links are.
Having to Tab through items that aren’t visible on the screen is a terrible user experience!
Checking the Opened Submenu
Opening the menu with the mouse and tabbing in shows that the first link has been focused. The focus outline is only visible because the wildcard outline: 0; CSS has been temporarily disabled in DevTools. There are definitely some things to fix with this experience!
Video Transcript
I'm gonna go back to the homepage and and let's go start poking around. So I know that things are, there's some reachable components, right? We saw the status bar in the bottom left corner, but what the heck is going on with the visible focus style? So the first thing I do when I encounter this is do control, click on something that I believe should be focusable like the logo or the mega menu.
And I can come in here and look in the Chrome developer tools. And I see there is an anchor with an HF, so it should be focusable. And when I tapped through here, I see local host port 1, 2, 3, 4, which is the base domain for the website we're looking at. And the HF for this logo is a slash. So get me back to the homepage or the root of the website.
So that is this link that we're focused on, but there's no focus style. So right away, I know there's some issue with the CSS. So the presentation and styling layer of this has something that's keeping the focus from being visible in the browser dev tools. We have a really handy thing that we can use to identify what's going on.
So in Chrome dev tools, under styles, On the elements panel, there's this colon HOV for hover. So if I click that, I can force the element state and click on focus. And when I've selected this item, that should be focusable over here in the styles panel. Aha. I may have found what the issue is. So there's a wild card selector in our style sheet for every element on the page.
That's what this wildcard matches. And it's got an outline, none or outline zero. So if I turn that off and then come in here and focus. Now, this element has a blue focus outline. That's the default in the Chrome browser. So that seems pretty promising. I know that if I go and remove that style from the style sheet, hopefully it will help our situation with the mega menu or sorry with the logo link, the mega menu also has problems.
So let's see what's going on there. Cuz I'll tend to go and diagnose a few issues at once. Then I'll go over to the code, make some changes, come back. If I have access to the code that is sometimes I'm looking at a website, I don't have any control over and I can go and figure out what's going on, but I may or may not be in a position to fix it.
In this case, we are, we can go and make these changes. So we've got the logo diagnosed, let's look at the mega menu.
So for each item in this flex box menu, it's in a, a nav element and there's some divs, well here's a problem plan. Your trip is not a focusable element. It's marked up with a div. So a div element is not focusable, it doesn't have any semantic accessibility information in it.
And so we've got multiple problems with this. So with CSS, this I guess CS and yeah, it's only CSS at this point. We can hover on this and do a lot with interactivity, but we need we need more to make it actually work with the keyboard and with the screen reader. So for this element, this div is not, not really doing the trick.
It needs to be something like a button element. That would be a focusable element that we could swap out for the div. And then each one of these top level items, I'm gonna make the design decision that these items are purely there to toggle the mega menu and it's section, I'm not gonna have those navigate anywhere.
I would have to change the design somehow, cause you can't really open a mega menu and navigate on the same item without it being kind of confusing and sort of hacky to try and code that way. So I'm gonna have these top level items let's change 'em to buttons so that they're focusable and with this outlined Nu style out of there, we should be able to see where we are.
So there's that problem. There's also the fact that when I'm tabbing through here, there's all these links showing up, right? So what are those? I just saw passes. Oh, there's our focus style. So I turned that outline none off. I can see where I'm focused when the menu is open, but when the menu is closed, I shouldn't be able to reach those items as a keyboard user.
I shouldn't be forced through elements that are invisible to mouse users and people who can see the screen make stuff really confusing. Like if you use the keyboard and you can see the screen, but you're getting stuck in these hidden layers, a terrible experience. So these mega menu sub menus should be hidden from everyone when they're not open.
So we need a little bit of CSS to change how the mega menu works. And that way I can skip by those mega menu sub menus when I'm using the keyboard. So there's three things we could fix so far, the outline, none the buttons on the top level items and the visibility of the mega menu sub menus. And I've figured this out just by using the keyboard and tapping through here and looking at the dev tools.
So mega menu, sub menu. If we come and look at the styles for that, it has opacity zero to, and maybe let's see height zero opacity, zero, and overflow hidden. So visually it's hidden, but with opacity and height, there's nothing stopping the keyboard from still focusing on those items. So what we really need is something like display none instead.
So if I change this right here on the fly, I can kind of validate that that will help me avoid tabbing into mega menu sub menus that I shouldn't be able to reach. So I'm still not reaching these top level items, but I'm also not having to focus on all those sub menu links that I shouldn't be able to reach.
So. Okay, cool. So I guess that's my tip number. What are we on? Number three? so tapping through the keyboard, inspecting with the dev tools and then actually fidling with the dev tools and making changes on the fly to say, is that gonna affect anything? Like we turned off outline none. I changed the display property so I can sort of validate changes in the browser before I go and make changes to the source code.
But that's exciting. We've already got some changes to make.
Next Steps
If you’d like to to work through fixing these issues, move on to the Fix Focus and Operability Issues Challenge.
Otherwise, visit the improved & deployed version of CampSpots and see how the behavior has changed. Inspect elements and compare the before and after in DevTools. Keep in mind, we will make additional improvements for Assistive Technologies in a later module.
When you’re done, skip over to the Developer Tools module.